Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@hyperfleet-bug-triage/scripts/track-usage.sh`:
- Around line 89-96: The backgrounded GitHub dispatch in track-usage.sh (the `gh
api repos/openshift-hyperfleet/hyperfleet-claude-plugins/dispatches` call that
uses USERNAME, PLUGIN_NAME, SKILL_NAME and EVENT) still ties up the invoking
process because its stdio is inherited; detach its stdio so it truly runs
non‑blocking by redirecting stdin from /dev/null and sending stdout/stderr to
/dev/null (or using nohup) and backgrounding/disowning the process, ensuring the
command does not keep the capture pipe open and block skill loading.

In `@hyperfleet-bug-triage/skills/bug-triage/SKILL.md`:
- Around line 211-212: Update the triage rules so GitHub issues are not closed
based solely on a linked Jira ticket's status: change the rule that currently
says "If Jira ticket exists: comment on GitHub linking to it, add
`hf-triaged/accepted` label, close the issue if the Jira ticket is already
Closed/Done, skip" to instead comment and add the `hf-triaged/accepted` label
but do NOT close the issue based on Jira status; only close when there is a
linked PR that is merged or the fix is present in the repository. Similarly,
update the rule that handles "If code already fixed: comment referencing the PR,
add `hf-triaged/accepted` label, close the issue" so it only closes issues when
the referenced PR is merged (or the fix is in trunk), and otherwise leave the
issue open while tracking the PR.
- Around line 18-26: Update the consent flow in SKILL.md so an empty reply is
NOT treated as consent: require an explicit affirmative "yes" (case-insensitive)
to opt in when the dynamic context is TRACKING_CONSENT_NEEDED, and only then run
the TRACKING_RERUN command; treat any other response (including empty) as a
decline. Also correct the data description—do not call it “anonymous”;
explicitly list the fields sent (e.g., GitHub username and invocation counts as
emitted by hyperfleet-bug-triage/scripts/track-usage.sh around line 92) so the
prompt and subsequent wording accurately reflect what is collected.
- Around line 183-186: The GitHub CLI command uses a BSD-specific date
expression created:<$(date -v-42d '+%Y-%m-%d') which breaks on GNU/Linux;
replace the inline date usage in the gh api search/issues q=... string by
computing a DATE variable using a portable fallback (try GNU: date -d '42 days
ago' +%Y-%m-%d and if that fails fall back to BSD: date -v-42d +%Y-%m-%d), then
inject that DATE into the q=... created:<$DATE portion of the gh api
search/issues invocation (refer to the gh api search/issues command and the
created:<$(date ...) fragment to locate the change).

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@hyperfleet-bugs-triage/skills/bugs-triage/SKILL.md`:
- Around line 182-187: The date command in the gh api search snippet uses
BSD-specific syntax ("date -v-42d") which breaks on GNU/Linux; edit the code
block in SKILL.md where the gh api search/issues command is defined and replace
the hardcoded BSD call with a portable fallback (e.g., try "date -d '-42 days'
'+%Y-%m-%d'" and fall back to "date -v-42d '+%Y-%m-%d'" if the first fails) or
document macOS-only requirements; update the quoted q=... expression to use that
portable substitution so the gh api search/issues command works on both Linux
and macOS.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@hyperfleet-bugs-triage/skills/bugs-triage/SKILL.md`:
- Around line 142-144: The markdown tables use fenced code blocks without
language identifiers (MD040); update each triple-backtick fence that wraps the
tables (the blocks containing "| Ticket | Priority | Status | Assignee | Created
|", the metric tables, and the other table blocks around lines noted) to include
a language tag (e.g., ```markdown) so each fenced block becomes labeled (for
example change ``` to ```markdown) for all occurrences referenced (including the
blocks at ~142-144, 150-159, 259-261, 265-277).

---

Duplicate comments:
In `@hyperfleet-bugs-triage/skills/bugs-triage/SKILL.md`:
- Around line 20-24: Update the consent prompt and handling so it requires an
explicit "yes" (case-insensitive) to opt in — do not treat empty input or any
other response as consent — and correct the wording to list the precise data
collected ("GitHub username and skill invocation counts") instead of
"anonymous"; when the user explicitly agrees run a single Bash command that
creates the consent file, writes "yes", and then runs the actual TRACKING_RERUN
command shown in the SKILL.md `TRACKING_RERUN:` line (replace the
`<TRACKING_RERUN command ...>` placeholder with that exact command) using the
form: mkdir -p ~/.claude && echo "yes" > ~/.claude/.hyperfleet-tracking-consent
&& <actual TRACKING_RERUN command>; when the user explicitly declines run: mkdir
-p ~/.claude && echo "no" > ~/.claude/.hyperfleet-tracking-consent.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@hyperfleet-bugs-triage/README.md`:
- Around line 13-17: Add a language identifier to the fenced code block in
README.md that contains the usage examples (the block with the lines starting
"/bugs-triage", "/bugs-triage jira", "/bugs-triage github") so markdownlint
MD040 is satisfied; change the opening fence from ``` to ```bash (or another
appropriate language) to mark the snippet as bash.

In `@hyperfleet-bugs-triage/skills/bugs-triage/SKILL.md`:
- Around line 167-173: The GitHub search currently excludes only three triaged
labels and thus returns issues with other non-triage labels; update the gh api
search command's q parameter (the q="..." string in the gh api search/issues
call in SKILL.md) to explicitly require either unlabeled issues (no:label) or
issues labeled hf-needs-triage by changing the query to include (no:label OR
label:hf-needs-triage) while still excluding hf-triaged/accepted,
hf-triaged/rejected, and hf-triaged/duplicate; modify the q string accordingly
in the gh api search/issues invocation so it matches the documented intent.

In `@hyperfleet-jira/skills/jira-ticket-creator/references/formatting.md`:
- Around line 34-37: The fenced code block in formatting.md that contains the
two lines "**POST** /api/v1/clusters/:id" and "**GET** /api/v1/clusters/{id}" is
missing a language tag (triggering markdownlint MD040); update that fence to
include a language tag (e.g., text) so the opening fence becomes ```text,
leaving the block contents unchanged and preserving the bold method examples.

Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In `@hyperfleet-bugs-triage/skills/bugs-triage/SKILL.md`:
- Around line 167-173: The GitHub search query in the gh api command in SKILL.md
currently selects any open issue that lacks the three triaged labels, but it
should only select issues that are either unlabeled or explicitly labeled
hf-needs-triage; update the -f q=... string used in the gh api search/issues
command (the snippet containing "is:issue is:open -label:hf-triaged/accepted
-label:hf-triaged/rejected -label:hf-triaged/duplicate") to instead use a
parenthesized expression combining no:label OR label:hf-needs-triage (e.g.,
is:issue is:open (no:label OR label:hf-needs-triage) and still exclude the three
hf-triaged/* labels) so the query matches only unlabeled or hf-needs-triage
issues in the listed repos.

---

Nitpick comments:
In `@hyperfleet-jira/skills/jira-ticket-creator/SKILL.md`:
- Around line 127-144: The doc currently contradicts itself: the "All fields can
be set via CLI during creation" section claims no post-creation work is needed,
but "Step 7: Verify and Return Details" still asks for a **List of manual steps
needed**; update SKILL.md to remove this conflicting bullet or explicitly
document which specific fields or post-creation actions (if any) cannot be
automated via CLI. Locate the "All fields can be set via CLI during creation"
statement and the "Step 7: Verify and Return Details" block (including the "List
of manual steps needed" line) and either delete that manual-steps line or
replace it with a short conditional note listing exact manual tasks and why
(referencing the CLI flags like -P, -l, -C and the jira issue view command for
verification).

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@hyperfleet-bugs-triage/skills/bugs-triage/SKILL.md`:
- Around line 273-274: The policy line "Use `jira` CLI for Jira and `gh` CLI for
GitHub — no other tools" conflicts with the declared allowed-tools; update the
wording in SKILL.md to permit the required toolchain by replacing that line with
a statement like: "Use `jira` CLI for Jira and `gh` CLI for GitHub; do not use
other external CLIs, but allowed-tools (AskUserQuestion, Read, Skill) may be
used as declared." Ensure the change references the existing phrase "Use `jira`
CLI for Jira and `gh` CLI for GitHub" and the allowed-tools entries
(AskUserQuestion, Read, Skill) so the doc and runtime tool list are consistent.
- Line 118: The Close command line uses a pipe-delimited resolution string which
conflicts with the file's placeholder style; update the Close example (the line
containing: jira issue move TICKET-KEY "Closed" --resolution "Won't
Do|Rejected|Duplicate") to use the same placeholder convention—either replace
the pipe syntax with an angle-bracketed alternatives placeholder like
--resolution "<Won't Do|Rejected|Duplicate>" or, better, use a single
descriptive placeholder such as --resolution "<Resolution>" and list the
acceptable values elsewhere for consistency.

---

Nitpick comments:
In `@hyperfleet-jira/skills/jira-ticket-creator/SKILL.md`:
- Around line 141-144: The "List of manual steps needed" section is currently
always shown and can be misleading when there are no follow-up actions; update
the SKILL.md output generation so the manual steps block (the "List of manual
steps needed" / "manual-steps" section) is emitted only when there are actual
manual steps to perform (e.g., render "Manual steps (if any):" or include the
whole list only when the manual-steps array/field is non-empty), ensuring other
fields like "Link" and "Summary of what was created" remain unchanged.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@hyperfleet-jira/skills/jira-ticket-creator/references/pitfalls.md`:
- Around line 28-30: The fenced code block containing the literal "Error:
customfield_12311141: Epic Name is required." is unlabeled and triggers MD040;
add a language tag (e.g., change the opening fence from ``` to ```text) so the
block reads as a text code fence, keeping the block content unchanged to satisfy
markdown linting.

---

Nitpick comments:
In `@hyperfleet-bugs-triage/skills/bugs-triage/SKILL.md`:
- Around line 153-157: The description text says the query returns issues that
are unlabeled or labeled hf-needs-triage, but the actual gh api search/issues
command filters for any open issue missing hf-triaged/* labels; update the prose
in SKILL.md to match the command by explicitly stating that the query returns
open issues across the repos listed in references/github-repos.md that do not
have any hf-triaged/* labels (not just unlabeled or hf-needs-triage), and
mention the specific labels (hf-needs-triage and hf-triaged/accepted,
hf-triaged/rejected, hf-triaged/duplicate) so readers understand the exact
filter used by the gh api search/issues command.

Verify each finding against the current code and only fix it if needed.

Duplicate comments:
In `@hyperfleet-bugs-triage/skills/bugs-triage/SKILL.md`:
- Around line 153-173: Replace the hardcoded repo lists used in the two gh api
search/issues commands with a dynamically built REPOS variable: add a small
command block that parses references/github-repos.md to extract repository slugs
and prefixes them with "repo:openshift-hyperfleet/" (store result in REPOS),
then update both gh api search/issues invocations (the commands that start with
gh api search/issues -X GET and include the long repo:openshift-hyperfleet/...
list) to use "$REPOS" in the -f q="... $REPOS" fragment instead of the inline
list; ensure the parsing handles the markdown list format used in
references/github-repos.md and that $REPOS is properly quoted in the query
string.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@hyperfleet-bugs-triage/skills/bugs-triage/SKILL.md`:
- Line 88: The component list in SKILL.md's header ("Component identified |
PASS/FAIL/MISSING | Must be: API, Adapter, Sentinel, Broker, Architecture")
doesn't match the canonical names in references/owners.csv, causing exact-match
owner lookups to fail; update that header to use the exact component names found
in owners.csv (e.g., "Hyperfleet API", "Adapter", "Sentinel", "Broker", "CICD")
and ensure any mention of "Hyperfleet Architecture" is clarified or mapped to
the correct component name in owners.csv so the assignee suggestion logic can
match strings exactly.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@hyperfleet-bugs-triage/skills/bugs-triage/SKILL.md`:
- Around line 153-173: Extract backtick-wrapped repo names from
references/github-repos.md, transform each name into the token prefixed with
"repo:openshift-hyperfleet/" and join them into a single space-separated
variable (REPO_FILTERS); then substitute that variable into the gh api search
queries used in the "untriaged" and "open > 3 sprints" steps so the -f q="..."
parameter contains $REPO_FILTERS instead of literal REPO1/REPO2 placeholders.
Use a robust markdown-safe extraction (capture text between backticks), ensure
empty lines produce an empty filter and short-circuit to reporting "No untriaged
GitHub issues" when the result set is empty, and apply this same REPO_FILTERS
substitution for both query blocks referenced in the SKILL.md examples.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@hyperfleet-bugs-triage/skills/bugs-triage/SKILL.md`:
- Around line 55-56: Several commands (notably the jira query string "jira issue
list -q\"project = HYPERFLEET AND status = New AND issuetype = Bug\" --plain
--columns \"KEY,SUMMARY,PRIORITY,STATUS,COMPONENT,ASSIGNEE,CREATED\"" and other
GitHub/Jira queries) currently append the stderr suppression token
"2>/dev/null", which hides auth/API/query errors and can falsely indicate "no
issues." Remove the "2>/dev/null" redirection (or capture stderr instead) and
explicitly check the command's exit status ($? or equivalent); if non-zero, log
or surface the error and fail/branch appropriately before treating the output as
"none found." Ensure all other occurrences of "2>/dev/null" applied to primary
fetch commands are handled the same way.